Обсуждаются сделанные из картона фигуры: квадрат, прямоугольник и неправильный четырехугольник. Мы детально обсуждаем их свойства. Прежде всего, у всех фигурок — по четыре угла. Значит, каждую из них мы можем назвать четырехугольником. Итого: у нас три четырехугольника.

При этом два из них отличаются тем, что у них все углы прямые. За это их называют прямоугольниками. Один из двух прямоугольников особый: у него все стороны одинакового размера. Его называют квадратом.

У квадрата как бы три имени: его можно назвать и квадратом, и прямоугольником, и четырехугольником — и все будет правильно.

Моя информация встречается не без сопротивления. Дети упорно стремятся мыслить в понятиях непересекающихся классов.

Другой пример:

— Являются ли папы и дедушки мужчинами, а мужчины — людьми?

Мне кажется, это отличная аналогия для классов эквивалентности! В один класс эквивалентности мы собираем все значения, для которых система должна (по нашему мнению) работать одинаково. Простые числа, мужские имена, и так далее. Чтобы не проверять всё множество вариантов, мы проверяем одно значение из класса.

И когда мы пытаемся выделить класссы, мы придумываем разные бизнес-сценарии для поля. Это и будут разные классы, разные строки в нашем чек-листе проверок. Проблема в том, что одно и то же значение может быть в разных классах. Например, имя «Ольга»:

• Распространенное имя
• Женское имя
• Средняя длина строки
• С буквой, которая одинаково выглядят на русском и на английском
• ….

И это ступор — как так? Ведь классы не должны пересекаться! Но Ольга может быть женщиной, дочкой, мамой, бабушкой, женой, человеком…

Классы эквивалентности могут пересекаться. И это нормально.

При составлении чек-листа проверок наша задача:

1. Найти как можно больше идей для тестов, выделить разные классы.
2. Удалить дубли.

Первый шаг — мозговой штурм. Если пытаться сразу и идеи накидывать, и отсекать лишние, придумаете намного меньше, чем могли бы. Стандартные правила мозгового штурма — на этапе генерации идей не отсекаем НИЧЕГО, даже «глупая идея» может по цепочке ассоциаций привести к гениальной.

Отсекать будем потом. Поэтому на этапе написания чек-листа не переживайте, если примеры для вроде бы разных тестов пересекаются.

Если говорить о программе:

• UI-тесты — честные тесты, «как это делал бы пользователь». (они же GUI, graphical user interface)
• API-тесты — опускаемся на уровень ниже, выкидывая лишнее.
• Unit-тесты — тесты на отдельную функцию

Начинаем писать тесты снизу, потому что сначала логичнее проверить небольшой участок кода, а потом усложнять:

• Unit — тесты на отдельную мелкую функцию (посчитать одну ячейку отчета)
• API — тесты на конкретный функционал, который состоит из отдельных функций (загрузить весь отчет)
• GUI — честный тест через графический интерфейс, «как это делал бы пользователь» (открыть браузер, войти в систему, перейти в отчеты, и наконец вызвать отчет).

В качестве аналогии давайте рассмотрим создание платья. Вот я заказала себе платье по фигуре. Мастер выслушает мои пожелания, снимет мерки, а потом приступит за работу. Сначала он сделает выкройку и раскроит ткань. Если проверять каждую деталь, сравнивая с выкройкой — это будут юнит-тесты.

Проверили каждую деталь отдельно? Теперь тестируем вместе. Обметали и смотрим — ровно? Криво? Может, что-то подправить?

Это аналог api-тестов — платье еще не готово, это не конечный продукт. Но мы соединили отдельные детали вместе и смотрим, как они работают.

Если всё хорошо, можно шить! А дальше следуюет аналог UI-тестов — последняя проверка, когда платье уже готово.

Нигде не накосячили? Когда все вместе собрано и рукав к попе пришит, переделывать уже очень трудно и дорого, такие проблемы лучше обнаружить заранее.

А еще одну аналогию можно провести с танцами

Начинаем с основ. Сначала надо отработать движение, чтобы потом внедрять его в танец. Каждое конкретное движение — аналог unit-тестов.

Следующий этап — связать отдельные функции вместе. Зная 5 разных движений, мы начинаем связывать их под музыку. Это аналог api-тестов.

Каждую часть танца мы разрабатываем отдельно (как и разные куски api в программе).

А потом уже соединяем всё вместе. И получается готовый танец. Аналог UI-тестов.

Итого

Соберем всё вместе. В программе:

• unit — тесты на отдельную мелкую функцию (посчитать одну ячейку отчета)
• API — тесты на конкретный функционал, который состоит из отдельных функций (загрузить весь отчет)
• GUI — честный тест через графический интерфейс, «как это делал бы пользователь» (открыть браузер, войти в систему, перейти в отчеты, и наконец вызвать отчет).

На примере платья:

• unit — раскроили и с выкройкой сверили каждую деталь
• API — обметали и проверили
• GUI — когда уже платье полностью готово, проверяем еще раз

На примере танца:

• unit — одно движение показали, отработали
• API — связка из 3-5 движений, небольшой отрывок
• GUI — весь танец целиком

• Тестирование производительности
• Нагрузочное тестирование
• Стресс-тестирование

Моя коллега Ольга Алифанова привела прекрасный пример!

1. Производительность: как быстро машина разгонится до сотни

2. Нагрузка: как быстро она разгонится до сотни с 4 пассажирами и багажом

3. Стресс: при каком весе на осях у нее подломятся балки

PS — это выдержка из моей книги для начинающих тестировщиков, написана в помощь студентам моей школы для тестировщиков. 

• Логическая — ограничение, накладываемое логикой, не программой.
• Технологическая — ограничение, накладываемое используемой технологией
• Произвольная — ограничение, накладываемое аналитиком или разработчиком.

Типы границ на примере стиральной машинки

(Пример любезно предоставлен Юлией Мироновой)

У вас есть стиральная машинка.

1. Логическая: нельзя засунуть меньше 0 киллограммов белья. Это логика.

2. Произвольная: нельзя засовывать больше 1 кг махровых полотенец — так производитель написал в инструкции. Завтра напишет 1,5 кг — вот граница и поменялась.

3. Технологическая: нельзя засунуть больше, чем влезет в бак машинки. И вот это уже никак не изменить, без смены технологии, в данном случае самой машинки.

Обратите внимание, что в данном случае границы измеряются в разных величинах, полный бак белья может по-разному весить.

В IT тоже часто такое может быть. Например, произвольная граница у нас указана в символах, а технологическая будет в байтах, а разные символы содержат разное количество байт, поэтому может оказаться, что в символах точную длину не указать.

PS — это выдержка из моей книги для начинающих тестировщиков, написана в помощь студентам моей школы для тестировщиков

Официальная часть

• Тест-кейс.
• Чек-лист (TBD, статья в разработке, пока можно почитать «Какой результат писать в чек-листе»).

Но моим студентам все равно тяжело. Зачем в тест-кейсе писать, что именно за файл создается, как его загружать в систему (на какие кнопки нажимать, какие действия выполнять)?

Идея 1

Я предложила им такое пояснение:

Тест-кейсы тупые до невозможности, словно ребенка на работу привели и показываем, «Вот мамочка сейчас файл обработает. Нажимаем кнопочку А, потом кнопочку Б, потом…«, а не просто «Ну вот загрузили и все получилось«.

Ну а чек-листы — это когда не нужны все эти подробности, как именно мы загружаем файлы, на какие кнопочки нажимаем. Нужна просто напоминалка — «Проверить загрузку Excel, CSV, JPG…»

Ребятам пояснение очень понравилось. Сказали, что так понятнее

Идея 2

Вы делали ремонт? Покупали шкафы, собирали их? А я делала и отсюда у меня вторая ассоциация.

Мы купили комод в ИКЕА. Он небольшой и простой в сборке. Но инструкция выглядит как талмуд — все настолько подробно. Каждое действие, каждый шаг. Каждый винтик — все в новом пункте на пол-листа А4, максильно доступно. Такой комод соберет даже полный профан. Потому что ребята не считают нужным пропускать этапы как «Ну это же очевидно, куда ввинчивать этот шуруп». Очень напоминает «Ну это же очевидно, на какую кнопочку нажимать, чтобы загрузить файл»

А вот диванчик в коридор мы купили в другом месте. Он тоже небольшой и не сильно сложный в сборке — кубик шкафчика собрать и прицепить к самому диванчику. Но инструкция — полный швах. На ней ровно одна картинка — уже собранный диванчик, все детали чуть на расстоянии друг от друга. Ну это же очевидно, как его собрать!

Мы, кстати, не осилили, оставили мастеру

Но разница «Простая инструкция — инструкция из ИКЕА» === «Чек-листы — Тест-кейсы». Когда будете писать тест-кейс, помните об этом и о том, что очевидное вам — темный лес для кого-то другого…

© Оригинальный блог-пост

В летней школе тестировщиков Алексей Баранцев вел тренинг для продвинутых, как искать баги и исследовать приложение. Он задал простой вопрос → «Чем отличаются ошибка, дефект и сбой?». Предположения были самыми разнообразными, но уловить тонкую грань отличий никто не смог. Алексей мог зачитать умные слова из справочника ISTQB, но предпочел рассказать историю. Три года прошло! Я помню историю до сих пор и могу назвать отличия без подглядывания в гугл

Вступление от Алексея — придумал историю не сам. На одном из тренингов я задал этот вопрос. Девочки посовещались между собой и сказали: «Мы не можем объяснить это с точки зрения ПО, но можем на примере шитья». Я удивился и сказал: «Давайте!».

Жил-был мастер. Он шил платья на заказ. Однажды он допустил ошибку — забыл прошить нижний край у кармана платья.

Результатом ошибки стал дефект. Платье висело на вешалке и выглядело абсолютно нормально, но оно было с дефектом.

Маленькая девочка увидела платье и сразу влюбилась. Она купила платье и носила его повсюду. И все было хорошо, платье сидело замечательно, дефект никак не проявлялся. Пока новая хозяйка не решила положить в карман ключ.

Девочка опустила руку в карман, отпустила ключ… У-у-у-упс, ключ выпал на пол! Произошелсбой в системе — проявился ранее скрытый дефект.

Точно также бывает и в ПО → разработчики допускают ошибки при написании кода и в программе затаивается дефект. И даже если дефект не нашли и о нем никто не знает, он все равно есть! Сидит и ждет своего часа. И когда пользователь натыкается на ошибочный код, происходит сбой.

Официальное определение

А под конец немножко официоза — версия из ISTQB:

A human being can make an error (mistake), which produces a defect (fault, bug) in the code, in software or a system, or in a document. If a defect in code is executed, the system will fail to do what it should do (or do something it souldn’t), causing a failure. Defects in software, systems or documents may result in failures, but not all defects do so.

Человек может допустить ошибку, которая приводит к дефекту (к неисправности, багу) в коде, в софте или системе, или документе. Если дефект в коде исполняется, система не сможет сделать то, что должна (или то, что не должна), что вызовет сбой. Дефекты в программном обеспечении, системах или документах, могут вызвать неисправности, но не все дефекты вызывают их.

© Оригинальный блог-пост